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Abstract  -  The  National  Oceanographic  and  Atmospheric  Administration  (NOAA)  and  the  Naval  Meteorology 
and  Oceanography  Command  (NAVMETOCCOM)  intend  to  collaborate  on  software  architectures  used  to 
enable  the  processing  and  dissemination  of  scientific  data  and  products  for  their  respective  missions.  This 
collaboration  supports  the  goals  of  the  U.S.  Integrated  Ocean  Observing  System  (IOOS).  This  paper  explores 
some  potential  areas  and  approaches  for  collaboration,  enabled  by  the  Service  Oriented  Architecture  model. 


I.  INTRODUCTION 

Addressing  data  integration  from  disparate  Department  of  Defense  (DoD),  Federal  and  non-federal  systems 
raises  many  collaboration  issues  beyond  those  encountered  in  typical  data  integration  scenarios.  At  the 
OCEANS  US  Airlie  House  workshop  in  2002  [1],  a  number  of  Federal  Agencies  (the  National 
Oceanographic  and  Atmospheric  Administration  (NOAA),  Navy,  the  Environmental  Protection  Agency 
(EPA),  et  al)  and  academic  institutions  identified  the  need  for  a  coordinated  network  of  people  and 
technology  that  would  work  together  to  generate  and  disseminate  continuous  data  on  our  coastal  waters, 
Great  Lakes,  and  oceans.  This  group  recognized  the  need  to  collect  and  integrate  this  data  in  a  manner  that 
would  ensure  it  could  be  used  to  better  characterize  and  understand  our  Nation’s  oceans  and  coasts.  This 
vision  was  formalized  in  December  2006,  when  the  NOAA  Executive  Council  and  NOAA  Executive  Panel 
approved  the  formation  of  NOAA’s  Integrated  Ocean  Observing  System  (IOOS)  Program  within  the 
National  Ocean  Service. 

IOOS  is  a  major  shift  in  our  approach  to  ocean  observing,  drawing  together  many  networks  of  disparate 
Federal  and  non-Federal  observing  systems  into  a  “system  of  systems”  to  produce  data,  information,  and 
products  of  common  interest  at  the  scales  needed  to  support  decision  making.  Once  completed,  IOOS  will 
be  a  nationally  important  infrastructure  enabling  many  different  users  to  monitor  and  predict  changes  in 
coastal  and  ocean  environments  and  ecosystems.  This  infrastructure  is  critical  to  understanding, 
responding,  and  adapting  to  the  effects  of  severe  weather,  global-to-regional  climate  variability,  and  natural 
hazards. 

The  development  of  an  integrated  data  management  system  for  rapid  access  to  diverse  data  from  disparate 
sources  is  the  current  highest  priority  for  IOOS  implementation.  The  IOOS  interface  for  most  users  will  be 
through  the  Data  Management  and  Communications  subsystem  (DMAC).  The  DMAC  will  knit  together 
the  global  and  coastal  components  of  the  IOOS  and  will  link  every  part  of  the  observing  system  from  the 
instruments  to  the  users,  and  will  contribute  to  defining  the  quality  of  the  end  products.  The  DMAC 
subsystem  is  required  to  transmit  multidisciplinary,  multi-media  observations  from  a  broad  range  of 
platforms,  and  transmit  them  (in  real-time,  near-  real-time,  and  delayed  modes)  directly  to  users  for 
processing  into  maps,  plots,  forecasts,  and  other  useful  forms  of  information.  The  goal  is  to  link  data  from 
buoys,  autonomous  drifters  and  vehicles,  ships,  aircraft,  satellites,  observatories,  and  other  platforms  to 
models  (e.g.,  GIS,  numerical  models,  statistical  models)  for  rapid  analysis  and  product  delivery,  while 
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ensuring  data  quality  and  usability.  The  DMAC  subsystem  consists  of  several  components  including  data 
transport  and  quality  control;  data  assembly  and  metadata  management;  data  archeology,  discovery, 
archival,  and  product  development;  and  associated  administrative  functions. 

This  paper  represents  the  collaboration  efforts  of  two  agencies  that  are  participants  in  the  IOOS/DMAC 
program:  the  Naval  Meteorology  and  Oceanography  Command  (NAVMETOCCOM)  and  the  National 
Oceanic  and  Atmospheric  Administration  (NOAA)  IOOS  Program  Office.  To  promote  the  interagency 
fielding  of  the  IOOS  DMAC,  NAVMETOCCOM  and  NOAA  have  entered  into  agreement  to  collaborate 
on  providing  respective  system  architectures  and  design,  software  baselines,  and  requisite  resident  expertise 
to  a  common  DMAC  baseline.  This  paper  describes  the  IOOS/DMAC  background,  the  respective 
capacities  of  the  agencies,  and  the  activities  to  be  conducted  under  the  terms  of  the  interagency  agreement, 
along  with  the  anticipated  results. 


II.  TECHNICAL  SUMMARIES  OF  EXISTING  PROGRAMS 

NAVMETOCCOM  maintains  a  software  capability  that  can,  in  part,  satisfy  the  DMAC  baseline 
requirements,  as  follows.  The  NAVY  METOC  Data  Services  Framework  (NMDSF)  provides  authoritative 
Naval  meteorological  and  oceanographic  (METOC)  data  to  the  Global  Information  Grid  (GIG)  through  a 
Jointly  defined  Community  of  Interest  (COI)  interface.  The  NMDSF  was  initiated  to  support  the  migration 
of  METOC  community  data  integration  mechanisms  to  align  with  the  tenets  of  the  GIG’s  Net-Centric  Data 
and  Services  Strategies. 

Traditionally,  tactical  decision  aids  and  other  applications  have  been  tightly  coupled  to  METOC  data 
sources  through  point-to-point  interfaces.  To  better  align  with  the  Net-Centric  Data  &  Service  Strategies, 
the  METOC  community  required  a  process  to  virtually  integrate  distributed  data  stores  into  a  single, 
METOC  Shared  Space  Environment.  METOC  Shared  Spaces  must  allow  posted  data  to  be  discoverable, 
visible,  accessible,  and  understandable  to  consumers.  Further,  applications  that  access  the  data  should  be 
loosely-coupled  with  regard  to  the  physical  location  and  identification  of  the  providing  node.  Three 
components  are  needed  to  achieve  these  goals:  a  standard  data  request/response  vocabulary,  service 
endpoints  that  implement  the  standard,  and  an  infrastructure  that  supports  routing  to  distributed  provider 
data  stores  and  synthesis  of  multiple  responses  into  one  for  the  consumer. 

The  requirement  for  a  standard  data  request/response  vocabulary  was  addressed  by  the  Joint  METOC 
Board  Data  Management  Working  Group  who  defined  the  Joint  METOC  Broker  Language  (JMBL). 

JMBL  is  implemented  in  Extensible  Markup  Language  (XML)  and  consists  of  a  series  of  DoD  registered 
schema  that  define  a  platform  neutral  Web  service  for  communicating  both  requests  for  METOC  data  and 
corresponding  responses.  JMBL  provides  a  uniform  request/response  message  format  for  Web  Services  to 
implement  access  to  METOC  data.  JMBL  supports  a  service  oriented  architecture  implementation  for  the 
METOC  enterprise  and  is  now  registered  in  the  DoD  IT  Standards  Registry  (DISR)  and  listed  there  as 
mandated.  The  second  and  third  components  are  enabled  by  the  NMDSF  design  and  implementation. 

This  framework  is  being  used  to  transform  proprietary  data  access  into  an  open  architecture-compliant 
enterprise  level  data  service  consistent  with  principles  of  a  Service  Oriented  Architecture. 

Establishment  of  NOAA’s  IOOS  Program  provided  for  a  Data  Integration  Framework  (DIF)  project  with  a 
nominal  duration  of  three  years,  from  February  1,  2007  to  February  1,  2010  [2].  The  DIF  was  originally 
limited  in  scope  and  scale  to  the  integration  of  data  from  three  NOAA  sources  of  five  core  IOOS  variables 
to  address  the  requirements  of  four  ocean  decision-support  tools  that  span  multiple  NOAA  mission  goals 
[3,  4,  5].  Shortly  after  project  inception,  the  list  of  core  variables  to  be  addressed  was  expanded  to  seven; 
water  temperature,  salinity,  water  level,  ocean  color,  water  currents,  winds  and  waves.  The  DIF  project 
objectives  are: 

•  Validate  the  premise  that  integrated  data  has  value  that  can  be  measured. 

•  Utilizing  the  principles  of  IOOS  Data  Management  and  Communications  (DMAC),  develop  a 
methodology  to  improve  upon  existing  ocean  data  integration  efforts  that  will  facilitate  flexibility 
and  extensibility  to  other  variables,  systems  and  decision-support  tools. 


•  Achieve  improved  integration  of  selected  data  sets  by  identifying,  adopting,  and  adapting 
community-developed  standards  for  data  content,  metadata,  quality  control,  and  transport  and 
deploying  these  standards  at  selected  data  sources  serving  the  four  decision-support  tools. 

•  Maintain  the  DIF  for  a  period  of  three  years,  from  project  inception,  to  conduct  adequate 
performance  monitoring  and  assessment  for  evaluating  and  measuring  progress. 


III.  ADOPTION  OF  NAVMETOCCOM  SERVICE  ORIENTED  ARCHITECTURE  STRUCTURES 


This  section  describes  the  characteristics  of  Service  Oriented  Architectures  in  general,  those  of  the  Navy 
METOC  SOA  and  the  proposed  adaptation  to  the  IOOS/DIF  implementation.  [6,  7] 

Implementation  of  a  net-centric  architecture  requires  a  transformation  of  IT  assets  from  platform-centric, 
standalone  applications/databases/systems  to  Web-based  applications,  net-accessible  services,  virtual 
shared  data  spaces,  and  a  broker  to  support  loosely-coupled  integration  between  collaborating  components. 
A  significant  enabler  of  this  architectural  transformation  is  the  creation  of  the  net-accessible  services  and 
integration  broker  that  supports  loosely-coupled  integration  within  and  across  organizational/enterprise 
boundaries.  These  mechanisms  are  the  essence  of  the  SOA  design  pattern. 

SOA  as  a  design  pattern  does  not  apply  to  all  aspects  of  IT  in  an  enterprise;  only  those  concerned  with 
creating  an  agile  integration  mechanism  between  capabilities  implemented  using  differing  technologies 
and/or  implemented  across  organizational/enterprise  boundaries.  In  other  words,  SOA  operates  at  the  edge 
of  an  organization’s  IT  capabilities  by  exposing  those  capabilities  and  selected  associated  data  most 
relevant  to  integration  with  multiple  internal  or  external  entities.  SOA  can  be  realized  by  identifying 
“major  integration  points”  for  internal  and  external  integrations.  To  wit,  the  following  concepts  apply  to 
the  common  architecture: 

•  Integration  between  the  Naval  METOC  Domain,  NOAA  IOOS  and  Consumers  should  use  SOA  to 
realize  integration  requirements.  Implementation  should  provide  access  to  METOC  and  IOOS 
capabilities  without  regard  to  actual  physical  location  of  the  capability  within  respective  domains  . 

•  Integration  between  the  physical  METOC  production  centers  (FNMOC  and  NAVO)  and  IOOS 
should  use  SOA  to  realize  integration  requirements. 

•  Integration  between  Sensor  Nodes  and  applications  and  databases  at  a  virtual  IOOS  Production 
Center  node  should  be  done  via  SOA.  Implementation  should  loosely-couple  the  actual  physical 
location  of  the  sensor  node(s)  and  the  specific  physical  location  of  the  applications/databases  at  the 
physical  METOC  production  centers. 

SOA  allows  creation  of  new  capabilities  by  composing  reusable  functionality  hosted  at  various  nodes  on 
the  enterprise/domain  network  and/or  other  accessible  networks.  This  reusable  functionality  is  made 
available  via  published  “service”  interface  descriptions  that  any  interested  and  authorized  consumer  can 
discover  and  access.  Three  key  architectural  components  are  required  in  an  SOA  implementation  to  enable 
service  providers  to  effectively  interact  with  a  broad  and  diverse  collection  of  consumers:  the  Service 
Integration  Layer,  the  Enterprise  Service  Bus,  and  the  Service  Endpoint  Infrastructure. 

Service  Integration  Laver  (SIL) 

A  SOA  assures  that  any  consumer  can  talk  to  any  provider  through  service  interfaces,  even  in  cases  where 
their  IT  infrastructures  are  based  upon  different  computing  servers,  operating  systems,  or  programming 
languages.  This  capability  is  provided  by  the  critical  design  characteristic  of  SOA  referred  to  as  “loose¬ 
coupling”.  In  this  case,  providers  and  consumers  are  loosely-coupled  with  respect  to  their  implementation 
technologies.  SOA  provides  this  by  requiring  that  service  interface  descriptions  are  based  upon  well 
known,  published  standards  that  are  broadly  implemented  by  most  if  not  all  IT  vendors.  The  SOA 
architectural  component  called  the  SIL  is  intended  to  provide  a  coherent,  mutually  supportive,  set  of  open 
service  interface  descriptions  that  represent  the  “major  integration  points”  to  an  organization’s  capabilities. 
A  major  integration  point  is  one  where  the  underlying  functionality  or  data  has  significant  use  (and/or  reuse 


potential)  across  the  internal  METOC  or  100S  Domains.  This  layer,  specified  for  the  Navy  METOC 
Domain’s  portfolio  of  METOC  COl  services  is  referred  to  as  the  METOC  Enterprise  Service  Integration 
Layer  (MESIL). 

Service  interface  designs  shall  be  influenced  not  only  by  the  functionality  to  be  provided  by  the  service  but 
also  by  the  structure  of  the  MESIL  itself.  The  MESIL  structure  shall  reflect  the  requirement  that  service 
interfaces  should  be  reusable  in  multiple  contexts  and  should  provide  a  degree  of  abstraction  and  loose¬ 
coupling  between  operational  process  logic  and  technology  specific  application  logic.  This  indicates  that  it 
may  be  appropriate  to  partition  the  MESIL  into  multiple  service  layers.  For  example,  one  such  layering  is 
reflected  in  the  following  service  taxonomy: 

•  Orchestration  Services:  These  contain  workflow  logic  for  specific  processes  and  sub-processes. 
These  should  link  directly  to  process  specifications  of  the  customer  and/or  METOC/IOOS 
production  processes. 

•  Business  Task/Entity  Services:  These  encapsulate  a  coherent,  specific,  but  significant  single 
business  task  or  entity  that  is  best  accessed  via  a  SOA  service  interface.  These  services  will  not 
contain  workflow  logic  so  that  it  will  be  reusable  across  multiple  processes. 

•  Application  Utility  Services:  These  map  fairly  directly  to  reusable  infrastructure  capability  that  is 
common  to  many  needs. 


Enterprise  Service  Bus  (ESB) 

In  order  to  achieve  the  stated  goals  of  SOA  and  net-centricity  in  general,  the  design  characteristic  of  loose¬ 
coupling  has  to  be  extended  to  other  facets  of  provider/consumer  interactions.  For  example,  by  providing 
an  architectural  component  that  handles  data  format  conversions  between  the  consumer  and  provider,  SOA 
can  support  “loose-coupling”  with  regard  to  data  formats.  This  sort  of  negotiation/translation  can  also  be 
extended  to  other  facets  of  provider/consumer  interactions  such  as  security  and  network  access  protocols. 
Together,  these  types  of  brokering  services  are  referred  to  as  mediation  services. 

In  a  net-centric  environment,  consumers  should  not  be  tightly  coupled  to  a  provider’s  specific  location,  or 
even  identity.  This  gives  great  flexibility  in  where  to  deploy  a  capability  on  the  network  and  supports 
access  to  alternate  service  providers  based  upon  enhanced  performance  needs.  Providing  a  message  broker 
capability  between  consumers  and  providers  extends  the  trait  of  loose-coupling  to  location  and  provider 
identity  transparency. 

Finally,  enabling  a  level  of  comfort  for  Program  Managers  to  use  services  provided  by  other  programs  and 
organizations  requires  very  clear  service  contracts,  called  Service  Level  Agreements  (SLAs),  and 
mechanisms  to  monitor  compliance  and  mitigate  degradation  of  performance.  This  suite  of  services  is 
called  Enterprise  Services  Management  (ESM). 

The  SOA  architectural  component  that  hosts  the  capabilities  is  referred  to  as  an  ESB.  This  architectural 
component  is  called  METOC  community  of  interest  Service  Bus  (MCSB). 

Service  Endpoint  Infrastructure 

The  third  enabling  element  of  an  SOA  consists  of  those  things  required  to  actually  implement  the  service 
interfaces  described  in  the  SIL.  These  components  are  attached  to  SOA  architectural  components  called 
Service  Endpoints;  locations  on  the  network  where  the  SIL  interfaces  are  implemented  with  scalable 
software  components,  middleware  infrastructure  (application  servers  w/  XML  and  web  service  toolsets), 
and  server  infrastructure.  In  the  METOC  Domain  this  is  referred  to  as  Node  Integration  Infrastructure 
(Nil).  The  Naval  METOC  Domain  will  deploy  such  integration  infrastructure  at  each  physical  node  that 
must  integrate  with  the  DoD’s  Global  Information  Grid  (GIG)  and  host  Naval  METOC  services.  In 
addition,  while  the  Naval  METOC  Domain  will  physically  host  NCES  type  services,  additional  hosting 
infrastructure  will  be  provided  at  METOC  Production  Center  nodes  for  these  core  services.  Core  Services 
integration  infrastructure  will  federate  across  multiple  nodes  to  support  the  realization  of  a  single  virtual 
node  for  the  Domain. 


To  connect  nodes  together  in  a  METOC  SOA,  the  following  concepts  apply: 

•  Naval  METOC  will  provide  content  to  a  Department  ofNavy  and/or  DoD  Enterprise  Portal  via 
“Remote  Portlets”  hosted  at  NAVMETOCCOM  nodes  -or-  code  will  be  hosted  directly  at  a 
DON/DoD  Portal  Site. 

•  Discoverable  COI  Service  Interfaces  will  expose  METOC  capability  to  providers/consumers. 

•  A  collection  of  common  core  services  will  support  reliable,  loose-coupled,  secure  interactions 
between  service  providers  and  consumers.  These  will  be  accessible  at  a  single,  virtual  access 
point  for  machine-to-machine  (M2M)  interactions.  It  is  expected  that  DoD  will  provide  the  bulk 
of  these  capabilities,  but  Naval  METOC  (like  other  enterprises  or  domains)  will  be  required  to 
host  some  of  these  capabilities.  Without  an  ESB,  a  SOA  environment  can  repeat  the  problem  of  a 
plethora  of  P2P  interfaces  that  make  for  the  brittle,  less  agile  IT  environment  that  exists  today 

•  The  emergence  of  DoD  Core  Services  and  Naval  METOC  Core  Services  must  be  coordinated, 
both  in  a  strategic  and  technical  sense.  The  ESB  Bridge  represents  both  of  these  needs. 


The  implementation  of  the  principles  cited  above  in  the  NAVMETOCCOM  architecture  is  shown  in  Figure 

1. 


Figure  1.  Navy  METOC  Enterprise  “To  Be”  Architecture 


IV.  ADAPTATION  OF  NAVY  METOC  CONSTRUCTS  TO  IOOS/DIF 


Referencing  the  SOA  principles  cited  above,  the  following  observations  are  tendered  concerning  NOAA 
IOOS  DM  AC: 

•  DIF  is  largely  focused  as  an  ingest  engine  to  ingest  parameters  of  varying  complexity  (point, 
image,  map  coverage)  from  external  sensors  and  servers. 

•  The  integration  from  Sensor  Nodes  to  aggregation  points  is  currently  apparent  in  the  DIF  through 
the  experimental  use  of  the  Sensor  Observation  Services,  an  open  source  interface  standard 
developed  within  the  OGC  community  that  provides  an  API  for  managing  deployed  sensors  and 
retrieving  sensor  observations 

•  DIF  provides  means  to  integrate  multiples  of  instances  of  information  objects  into  stratified  data 
bases  that  are  further  parsed  into  the  seven  core  variables. 

•  DIF  is  a  subset  of  a  larger  architectural  strategy  for  DMAC,  to  include  SOA  implementation. 

•  Much  of  the  functionality  of  the  Navy  METOC  Data  Services  Framework  (NMDSF)  is  directly 
applicable  to  the  Utility  Services  layer  of  the  IOOS  architecture,  specifically  for  “Service 
Gateway”  and  “Data  Integration.” 

•  The  SOA  attribute  of  composability  will  allow  the  integration  and  loose  coupling  of 
NAVMETOCCOM  SOA  components  with  the  DIF  framework. 

•  The  Service  Gateway  of  the  DIF  architecture  equates  to  the  Service  Integration  Layer. 


Our  approach  for  integrating  the  planned  Naval  METOC  SOA  constructs  is  not  unique  to 
NAVMETOCCOM.  This  approach  has  applicability  to  a  broader  range  of  programs,  in  particular  to  the 
IOOS  DMAC.  Therefore,  the  following  general  approaches  are  proposed  for  this  collaboration: 

1.  Application  of  SOA  practices  to  DIF. 

2.  Implementation  of  NAVMETOCCOM-like  data  services  framework. 

3.  Instantiation  of  publicly  releasable  NAVMETOCCOM  data  in  DIF. 

The  overall  consolidation  of  these  points  is  reflected  in  the  Figure  2.  Figure  2  shows  a  representation  of 
several  service  layers  that  would  comprise  a  hypothetical  IOOS.  The  far  right  of  the  diagram  depicts  actual 
instances  of  working  functional  capabilities  in  use  by  NAVMETOCCOM  that  can  be  used  to  instantiate  the 
components  to  which  they  are  connected  by  a  single  line.  For  example,  NMDSF  is  a  multi-faceted 
component  that  meets  part  or  all  of  the  requirements  for  Service  Gateway,  Data  Integration,  Enterprise 
Service  Integration  Layer,  and  Enterprise  Service  Bus.  The  dashed  lines  represent  on  example  data  flow. 

In  this  case,  data  from  the  Wave  Watch  3  model,  operated  by  Fleet  Numerical  Meteorology  and 
Oceanography  Center,  passes  in  the  form  of  regular  grids  via  NMDSF,  to  support  the  Coastal  Inundation 
Model.  This  approach  will  allow  NOAA  to  make  use  of  various  types  of  publicly-releasable  information 
produced  by  NAVMETOCCOM. 


Much  of  the  specificity  for  this  sharing  of  services  is  yet  to  be  defined,  but  the  generality  that  is  enabled 
through  the  use  of  SOA  allows  these  services  to  be  combined  in  a  way  that  can  satisfy  many  of  the  IOOS 
requirements  through  re-use  of  existing  software.  The  general  SOA  principles  of  encapsulation, 
abstraction,  loose  coupling,  composability,  and  reusability  will  provide  economies  that  will  enhance  the 
abilities  of  NOAA  and  NAVMETOCCOM  to  deliver  mutual  IOOS  capabilities. 
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Figure  2.  IOOS  Component  Structure  with  NAVMETCCOM  analogues 
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